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54) Title: IMPROVEMENTS IN. OR RELATING TO. TEU -SERVICE MANAGEMENT SYSTEMS 



(57) Abstract 

A teicscivice management system is adapted to 
support the provision of a plurality of complex teleser- 
vices and has a plurality of intercommunicating sub- 
systems. The teteservice management system nego- 
tiates and settles agreements between participants to 
a service session, resource control architectures within 
terminals and a resource control architecture in a trans- 
mission network. The teleservice management system 
employs a teleservice control protocol for transmitting 
messages between said subsystems and thereby con- 
trolling a teleservice. The teleservice control proto- 
col is arranged to link a network resource manager, 
service users and terminal resource managers, into a 
teleservice control process for facilitating delivery of a 
teleservice which is optimal, in terms of resource us- 
age, and agreed by a service user. The teleservice con- 
trol protocol is adapted for use with a plurality of dif- 
ferent teleservices including: multiparty, multimedia 
conference services; tele-game services: tele-shopping 
services; and tele-education services. The teleservice 
control protocol messages refer to specific parts of an 
object oriented model of a teleservice session. The tele- 
service control protocol includes messages exchanged 
between: a terminal part and a network part of the 
teleservice management system; the teleservice man- 
agement system and a service control graphical user 
interface: the teleservice management system and an 
application launcher daemon; and the teleservice man- 
agement system and network resource managers. 
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Improvements in, or Relating to, Teleservice Management Systems 

The present invention relates to a teleservice management system, a 
sen/ice platform for managing a plurality of complex teleservices, a 
telecommunications system including a teleservice management system and a 
method of managing a plurality of complex teleservices 

The first worldwide telecommunication system, i.e. the digital telephone 
network, has been working for years. The allocation of resources with guaranteed 
service quality requirements, such as low delay and delay variation, for this single- 
service system was also solved a long time ago. Resource management is much 
more complicated in the case of broadband integrated services networks which 
support several multimedia, multi-connection, multi-party services with different 
requirements. 

In the case of normal telephony, the source terminal is allocated first, after 
lifting the phone-receiver, then the network resources are allocated as the CCSS 
#7 signalling message proceeds through the network and the destination terminal 
is finally allocated. If the called user answers within a given waiting time, the call 
is established. Otherwise the allocated resources are released in a reverse order. • 
This Bearer Service Layer protocol does not require management functions in the 
Teleservice Layer. 

Because of the complexity and diversity of broadband teleservices, the 
management functions have to be divided between the Service Management 
System and the Control Architecture. Since signalling messages in the Teleservice 
Layer are not yet supported by the current standards, a new protocol has to be 
designed. This can be considered as third party, overlay signalling, since it is up 
to the SMS to translate the Teleservice Layer messages to proper bearer signalling 
messages during call establishment, operation and release. Basically, two type of 
Bearer Service Layer protocols can be distinguished, the forward and backward 
allocation, depending on the direction of resource reservation between the source 
and destination terminals. 
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in our co-pending patent application, Telia Case 698 (Application No ), 

the content of which is imported herein by reference, there is described a 
teieservice management system which solves the following problems: 

the TSMS relieves the user from having to provide elaborate and 
comprehensive technical descriptions in order to invoke the service 
and to indicate service quality aspects; 

the SU cannot usually express his QoS preference, since the 
application does not ask him, therefore, the TSMS has an own 
Service Control interface for interaction with the user; 

allocation, and release, of telecommunication applications and 
resources in terminals and network; 

co-ordination and integration of telecommunication applications and 
resources in terminals and network; and 

controlling of resources from the service point of view, thereby 
maintaining the required quality of service, e.g. adapting resources, 
such as, communication bearer capabilities, according to different, 
or shifting, circumstances. 

This TSMS provides a general scheme for constructing new teleservices 
which facilitates the service definition, in general and, in particular, provides a 
systematic way of handling the different service options, which might otherwise 
degenerate into an unmanageably large set of possible service variants. 

The invention described and claimed in our co-pending application Telia 
Case 698 provides a teieservice management system adapted to manage a 
plurality of complex teleservices. This teieservice management system includes 
a service control module arranged to provide a user with a graphical interface 
adapted to enable the user to provide data on a required QoS and other 
parameters, relating to a teieservice which the user wishes to invoke. Means are 
also provided for storing information relating to service definitions. The teieservice 
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management unit creates an object oriented teleservice model from a request for 
service, received from said graphical interface via said service control module, 
using a default mapping between teleservice layer entities and bearer service layer 
entities. 

5 The present invention relates, inter alia, to a signalling protocol for 

transmission of control messages in a teleservice system of the type disclosed in 
our co-pending patent application Telia Case 698. 

Two further related inventions are described in our co-pending patent 
applications, listed below, the content of the specifications of these patent 
10 applications is incorporated into this patent specification by reference. The co- 

pending patent applications are: 

Telia Case 700 (our co-pending patent application ), which 

relates to a procedure for creating reservation graphs for the 
resources in terminals and networks using the teleservice 
15 description given by the sen/ice provider, said procedure being 

aimed at producing the most complete teleservice configuration 
consistent with service specific rules; and 

Telia Case 701 (our co-pending patent application ), which 

relates to a service control graphical interface for facilitating 
20 communication between a Teleservice Management System and a 

system user. 

The TCP of the present invention is unique. Many protocols exist for 
directly controlling the bearer network resources, e.g. establishing connections with 
given parameters. However, the TCP of the present invention controls the 
25 teleservice itself, i.e. it operates at a higher level and does not act directly on the 

resources. 

The difference between the TCP of the present invention and other 
teleservice level protocols is that the TCP herein described involves not only the 
network resource manager and the user application, but also brings the service 
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user and the terminal resource manager into the control process. This results in 
a teleservice session which is optimal from the resources' perspective and which 
is also acknowledged by service users. 

The type of the TCP's protocol primitives, and their order, are unique. 

The vast majority of teleservice control protocols are applicable to only one, 
or at most a few, teleservices, while the TCP of the present invention has general 
validity. 

The TCP messages used in the present invention refer to specific parts of 
an object oriented model of the teleservice session. 



According to a first aspect of the present invention, there is provided a 
teleservice management system, adapted to support the provision of a plurality of 
complex teleservices and including a plurality of intercommunicating subsystems, 
characterised in that said teleservice management system includes negotiation 
1 5 means for settling agreements between participants to a session, resource control 

architectures within terminals and a resource control architecture in a transmission 
network, said negotiation means including a teleservice control protocol for 
transmitting messages between said subsystems and thereby controlling a 
teleservice. 

20 Said teleservice control protocol may be arranged to link a network resource 

manager, service users and terminal resource managers, into a teleservice control 
process for facilitating delivery of a teleservice which is optimal, in terms of 
resource usage, and agreed by a service user. 

Said teleservice control protocol may be adapted for use with a plurality of 
25 different teleservices. 

Sard plurality of different teleservices may include: 

multiparty, multimedia conference services; 
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tele-game services; 

tele-shopping services; and 

tele-education services. 

Said teleservice control protocol messages may refer to specific parts of an 
object oriented model of a teleservice session. 

Said teleservice control protocol may be implemented in a teleservice layer 
and is transparently transferred in underlying layers. 

Said underlying layers may include network layers and transport layers. 

Said teleservice control protocol may include messages exchanged 
between: 

a terminal part and a network part of the teleservice management 
system; 

the teleservice management system and a service control graphical 
user interface; 

the teleservice management system and an application launcher 
daemon; and 

the teleservice management system and network resource 
managers. 

Said teleservice control protocol may have four primitives for communication 
within said teleservice management system. 

Said teleservice control protocol may have four primitives for communication 

with: 
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a sen/ice control; 

a terminal resource manager; 

a network resource manager; 

and an application daemon. 

Said teleservice management system may have the following interfaces: 

a first interface, between a terminal part and a signalling emulator; 

a second interface, between a terminal and a service control; 

a third interface, between a terminal and an application launcher 
daemon; 

a fourth interface, between a terminal and a terminal resource 
manager; and 

a fifth interface, between a signalling emulator and a network 
resource manager. 

Said teleservice control protocol may be adapted to transfer information 
relating to a part of a teleservice object model through said first interface. 

Said teleservice control protocol may be adapted to transfer information 
relating to a part of a teleservice object model through said second interface. 

Said teleservice control protocol may be adapted to transfer information 
relating to a name and parameters, associated with an application employed by a 
teleservice, through said third interface. 

Said teleservice control protocol may be adapted to transfer information 
relating to a specification of terminal resources, required by a teleservice, through 
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said fourth interface 

Said teleservice control protocol may be adapted to transfer information 
relating to a specification of network resources, required by a teleservice, through 
said fifth interface. 

According to a second aspect of the present invention, there is provided a 
telecommunications system, logically split between an application layer, a 
teleservice layer, a bearer service layer and a resource layer, characterised in that 
said teleservice layer includes a telesen/ice management system as set forth in any 
previous paragraph. 

According to a third aspect of the present invention, there is provided a 
service platform adapted to support the provision of a plurality of complex 
teleservices and including a plurality of intercommunicating subsystems, terminals 
and a telecommunications network, characterised in that said service platform 
includes resource management means, and in that a teleservice control protocol 
is employed for implementing protocol agents both in said terminals and in said 
network. 

Protocol agents may be implemented in said terminals by utilising a 
resource control application provider interface, forming part of a network control 
architecture, as an interface between network resource management and a signal 
emulator. 

Said terminals may have at least one interface towards a user. 

Said terminals may have an interface towards an application. 

Said terminals may have an interface towards a terminal resource manager. 

Said teleservice control protocol may be adapted for use with a plurality of 
different teleservices. 

Said plurality of different teleservices may include: 
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rnultiparty, multimedia conference -services; 

teie-game services; 

tele-shopping services; and 

tele-education services. 

Said telesen/ice control protocol messages may refer to specific parts of an 
object oriented model of a teleservice session. 

Said teleservice control protocol may have four primitives for communication 
within said teleservice management system. 

According to a fourth aspect of the present invention, there is provided a 
method of managing a plurality of complex teleservices employing a teleservice 
management system including a plurality of intercommunicating subsystems, 
characterised by settling agreements between participants to a session by 
exchanging messages using a teleservice control protocol, said teleservice control 
protocol linking a network resource manager, service users and terminal resource 
managers into a teleservice control process for facilitating delivery of a teleservice 
which is optimal in terms of resource usage and agreed by a service user. 

Said teleservice control protocol may operate with a plurality of different 
teleservices. 

Said plurality of different teleservices may include: 
multiparty, multimedia conference services; 
tele-game services; 
tele-shopping services; and 



tele-education services. 
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Said teieservice control protocol messages may refer to specific parts of an 
object oriented model of a teieservice session. 

Said teieservice control protocol may be implemented in a teieservice layer 
and transparently transfer teieservice protocol messages in underlying layers. 

Said underlying layers may include network layers and transport layers. 

Said teieservice control protocol may include messages exchanged 
between: 

a terminal part and a network part of the teieservice management 
system; 

the teieservice management system and a service control graphical 
user interface; 

the teieservice management system and an application launcher 
daemon; and 

the teieservice management system and network resource 
managers. 

Said teieservice control protocol may have four primitives for communication 
within said teieservice management system. 

Said teieservice control protocol may have four primitives for communicating 

with: 

a service control; 

a terminal resource manager; 

a network resource manager; 
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and an application daemon. 

Said teleservice management system may have the following interfaces: 

a first interface, between a terminal part and a signalling emulator; 

a second interface, between a terminal and a service control; 

a third interface, between a terminal and an application launcher 
daemon; 

a fourth interface, between a terminal and a terminal resource 
manager; and 

a fifth interface, between a signalling emulator and a network 
resource manager. 

Said teleservice control protocol may be used to transfer information relating 
to a part of a teleservice object model through said first interface. 

Said teleservice control protocol may be used to transfer information relating 
to a part of a teleservice object model through said second interface. 

Said teleservice control protocol may be used to transfer information relating 
to a name and parameters, associated with an application employed by a 
teleservice, through said third interface. 

Said teleservice control protocol may be used to transfer information relating 
to a specification of terminal resources, required by a teleservice, through said 
fourth interface. 

Said teleservice control protocol may be used to transfer information 
relating to a specification of network resources, required by a teleservice, through 
said fifth interface. 
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Embodiments of the invention will now be described, by way of example, 
with reference to the accompanying drawings, in which: 

Figure 1 illustrates the main messages of the teleservice control protocol 
of the present invention. 

5 Figures 2 to 8 show the blocks 2 to 8, respectively, of Figure 1, in greater 

detail. 

Figure 9 illustrates the environment of the teleservice control protocol of the 
present invention. 

Figure 10 illustrates the use of a mux for sharing a TSP/SIC signalling 
10 channel. 

Figure 1 1 illustrates mapping between messages. 

Figure 12 illustrates the process of implementing different operations on 
different objects in the same message. 

Figure 1 3 illustrates the process of modifying a LVSL 

1 5 Figure 14 illustrates the process of rolling back a LVSI. 

Figure 15 illustrates the process of object deletion in a LVSI. 

Figure 16 illustrates the process by which the Service Control in a terminal 
handles service dependent time-outs. 

20 Figure 17 illustrates the process of sending Inquiries to parties who have 

not sent a Reply. 

Figure 18 shows the contents of a Reply. 

Figure. 19 illustrates the basic flow for setting up a simple bearer sen/ice. 
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Figure 20 illustrates the basic flow for terminating a simple .bearer .service. 

Figure 21 illustrates how states in an object in the terminal and the 
corresponding object in the network change when messages are passed 
between them. 

5 Figure 22 illustrates the use of id. 

Table 1 lists objects of the Telecommunication Service Description Model. 

Table 2 lists typical messages for establishing a teleservice session 
between two parties. 

Table 3 contains the structure of a TSP Message. 

10 

Table 4 lists attributes in the class TSPJWSG. 

Table 5 lists a protocol Descriptor for a TSP Message. 

Table 6 contains the structure of a PDU for a TSP/SIC. 

Table 7 lists attributes in the class SIC_MSG. 
15 Table 8 is a table of message types. 

Table 9 contains the structure of a PDU for a USM Leg. 

Table 10 lists attributes in the class USM_LEG. 

Table 1 1 contains the structure of a PDU for a PARTYJ.EG. 

Table 12 lists attributes in the class PART_LEG. 
20 Table 13 lists attributes in the class ELEMENT HEAD IN LEG. 
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Table 14 is a table of Element Types. 
Table 15 is a table of Operations. 
Table 16 is a table of Responses. 
Table 17 is a table of Causes. 
5 Table 18 contains the structure of a PDU for a SIJHEAD. 

Table 19 lists attributes in the class SI_HEAD. 
Table 20 contains the structure of a PDU for the USMJELEMENT. 
Table 21 lists attributes in the class USM_ELEMENT. 
Table 22 is a table of presence in USM. 
10 Table 23 contains the structure of a PDU for an ASM_ELEMENT. 

Table 24 lists attributes in the class ASM_ELEMENT. 
Table 25 is a table of presence in ASM. 

Table 26 contains the structure of a PDU for a PARTYJELEMENT. 
Table 27 lists attributes in the class PARTY_ELEMENT. 
15 Table 28 is a table of presence in a PARTY_ELEMENT. 

Table 29 contains the structure of a PDU for PARTY J D. 

Table 30 lists attributes in the class PARTY JD. 

Table 31 contains the structure of a PDU for a PE ELEMENT. 
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Table 32 lists attributes in the class PE_ELEMENT 

Table: 33 is a table of presence in a PE_ELEMENT. 

Table 34 contains the structure of a PDU for a PAE_ELEMENT. 

Table 35 lists attributes in the class PAE_ELEMENT. 

5 Table 36 is a table of presence in a PAE_ELEMENT. 

Table 37 is a table for direction in a PAE_ELEMENT. 

Table 38 contains the structure of a PDU for a SM_ELEMENT. 

Table 39 lists attributes in the class SM_ELEMENT. 

Table 40 contains the structure of a PDU for an ACE_ELEMENT. 

10 Table 41 list attributes in the class ACE_ELEMENT. 

Table 42 contains the structure of a PDU for class 
TRAFFICJDESCRIPTOR. 

Table 43 lists attributes in the class TRAFFICJ3ESCRIPTOR. 

Table 44 is a table for type in the class TRAFFICJDESCRIPTOR. 

15 Table 45 gives the meaning of the attributes Operation, Response and 

Cause in an Order. 

Table 46 gives the meaning of the attributes Operation, Response and 
Cause in an Inquiry. 

Table 47 gives the meaning of the attributes Operation, Response and 
20 Cause in a Reply. 
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Table 48 gives the meaning of the attributes Operation, Response .and 
Cause in a CS. 

In order to assist the reader to a better understanding of this patent 
specification, a glossary of some the abbreviations used herein is set out below: 



ABB Application Building Block 

ACE ? 

AP Application Provider 

API ? 

APLD Application Launcher Daemon 

ASM Abstract Service Module 

ATM Asynchronous Transfer Mode 

CAC Call Admission Control 

EMMA Experimental Middleware for ATM 

GSMP ? 

IAPI IP/ATM Protocol Interface 

IP Internet Protocol 

LVSI Local View of Sen/ice Instance 

MoD Movie on Demand 

NAP Network Access Program 
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NAPI Native ATM Protocol Interface 

NIC ? 

NP Network Provider 

NRM Network Resource Manager 

5 PAE Party ASM Edge 

PE Party Edge 

QoS Quality of Service 

RR ? 

SC Service Control 

10 SI Service Instance 

SIC Service Instance Control 

SIGNE Signalling Emulator 

SM Service Module 

SMS Service Management System 

15 SU Service User 

TCSD Telecommunication Sen/ice Description 

TP Terminal Profile 

TRM Terminal Resource Manager 
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TCP 



TeleService Control Protocol 



TSMS 



TeleService Management System 



TSP 



Telecommunication Service Protocol 



UPC 



Usage Parameter Control 



UQL 



User Quality Level 



USM 



User Service Module 



Control of distributed multimedia services requires internal communication 
between the components of a teleservice management system (TSMS), employed 
to control provision of these services. Internal communication is needed in order 
to: 



settle agreements between those participating in a session and the 
resources employed in the provision of the service; 

control architectures within terminals accessing a service and the 
network providing transmission functions for the service; 

control the dynamic behaviour of a teleservice session; 

update the state models of the teleservice session, stored in the 
terminals and in the network. 



The present invention relates to a teleservice management system 
employing a teleservice control protocol which implements these functions. 

The Teleservice Control Protocol (TCP) is used by the sub-systems of the 
TSMS, of the present invention, for implementing the functions set out above. The 
TCP includes messages exchanged between: 
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the terminal part (EMMA) and network part (SIGNE) of the TSMS; 

the TSMS and the Service Control graphical user interface; 

the TSMS and the Application Launcher Daemon; and 

the TSMS and the Terminal and Network Resource Managers. 

It implies four primitives for communication within the TSMS, see Figures 
1 to 8. and four primitives for communication with: 

the SC; 

the Terminal Resource Manager (TRM); 

Network Resource Manager (NRM); and 

the Application Launcher Daemon (APLD). 

It should be noted that the blocks labelled 2 to 8 in Figure I are illustrated 
in greater detail in Figures 2 to 8, respectively. 



The typical order of messages and description of the primitives are given 
in Table 2. Table 1 lists the different information transferred through the different 
1 5 interfaces of the TSMS. 



The creation, modification and termination, of teleservice sessions proceeds 
using the same message types, but with different contents. There are several 
possible orders for TCP messages, depending on the availability of terminal and 
network resources and the answers of service users and applications. A typical 
20 example is given in Table 2. where the notation "10a" and "10b" means that these 

steps may happen simultaneously, or in any other order in time. 



10 
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The TCP is implemented in the Teleservice Layer and is, therefore, 
transparently transferred in the underlying layers, e.g. network and transport layers. 

The TCP, of the present invention, can be applied within a 
Telecommunication Service Management System. Due to the general nature of the 
5 teleservice modelling approach, the same protocol primitives can be applied to any 

teleservice, e.g. multiparty multimedia conference, tele-games, tele-shopping, tele- 
education, etc.. 

Moreover, the TCP can also be used in Service Platforms as an extension 
for Resource Management. In this case, protocol agents should be implemented 

10 both in the network and in the terminals. The former utilise the resource control 

API of the network control architecture, e.g. GSMP, as the NRM/SIGNE interface. 
The latter should have at least one interface toward the user and, optionally, tv/o 
more interfaces toward the application and the terminal resource manager. 
However, some of the functionality of TCP can be kept even if only the NRM and 

15 SC are involved in a negotiation. 

The invention can be placed on the top of a general network resource 
control architecture, so called switchlet, which, in this case, replaces the network 
resource manager. 



The operating environment of the present invention is illustrated in Figure 
20 9, which is self explanatory and will be readily understood by those skilled in the art. 

TSP is a family of protocols which sit on top of TCP/IP for Signalling in 
SIGNE 2. The family includes TSP/HTTP, TSP/REG, TSP/TCSD, TSP/DIR, 
TSP/SIC, TSP/MUX. The protocol will now be described, in detail, from the point 
25 of view of implementation on the terminal side of TSP/SIC. The way in which 

SIGNE 2 is implemented on the network side of TSP/SIC is not described. 

TSP/SIC is used for distribution of objects in the Service Instance to 
terminals. The objects in LVSI have one part that is local and another that is the 
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distributed part of the Service Instance in the network. Only attributes and services 
needed in the terminal's local view are in LVSI. The local part comprises attributes 
and services for communicating with the ABBs and the Service Control. 

The basic flow is as follows: 

1 . Order from the initiating terminal to the network. 

2. Inquiry from the network to the terminal. 

3. Reply from the terminal. 

4. Confirmed State from the network to the terminal 

The terminal sends an order to the network containing the user's request 
for a Service Instance. The network processes the order and sends out Inquiries 
to all parties to the service. 

The Inquiry can be a request for the whole Service Instance, or just a part 
of it. The Inquiry specifies what resources the terminal needs to allocate to 
participate in the inquired part of the service. Whether the user, at the terminal, 
needs to be questioned about the inquiry, or not, is service dependent. If needed, 
the Service Control may modify both the question to the user and the answer from 
the user, before sending a reply to the network. 

When the terminal has processed the Inquiry and allocated ABBs, it gives 
an answer by sending a Reply to the network. In the Reply, objects from the 
Inquiry are returned with a status of accept, or reject. The network processes the 
Inquiry and when the demands for setting up a SI is True t the network sends a 
Confirmed State to all those who sent a Reply. The Confirmed State tells the 
terminal about the Confirmed State of the SI. For ail objects that are active this 
mean that a connection is established and the ABBs can start sending and 
receiving . The network waits for late Replies and sends a new Confirmed State 
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Fig 19 shows a basic flow for setting up a simple bearer service using 2 
parties, one USM and one ASM. 

Fig 20 shows a basic flow for terminating a simple bearer service. 

When the SI is terminated an Inquiry is needed to tell the ABBs to finish the 
current session and stop sending. In this case the Confirmed State just indicates 
that termination has been completed in the network. The terminal is not allowed 
to throw away a LVSI before a Confirmed State says so. For ABBs that do not 
require precise terminations, the terminal (Service Control) may send a Reply 
before killing the ABB. Some types of ABB do not need to be killed, e.g. hardware 
video decoders. 

Figure 21 illustrates the way in which states in an object in the terminal and 
the corresponding object in the network change when messages are past between 
them. The example, illustrated by Figure 21, shows the successful creation of an 
object. 

The Order message contains Message head, SI_HEAD, USM legs, and the 
service part of the Party legs (not SMs and ACEs). 

The Inquiry message contains Message head, SI_HEAD, USM legs, the 
whole Party leg for the receiver of the message and the service part of the other 
Party legs. 

The Reply message contains Message head. SI_HEAD and the sending 
Party's whole Party leg. The USM leg contains only size_of_usm_leg and no 
objects. 

The CS message contains Message head, SI_HEAD. USM legs, the whole 
Party leg for the receiver of the message and the service part of the other Party 
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legs. 

The purpose of the messages is to update the other side's service instance. 
It contains the attributes from the objects in the SI, and in the LVS1, that are needed 
5 in the other end. 

A SIC message holding one buffer for USM legs and one for Party legs is 
put into a TSP message. In the USM leg and the PARTY leg the sequence is 
important, it provides information about relations downwards of the legs for 
10 example, which USM an ASM belong to, which Party a PE belong to, and so on. 

The structure of messages will now be described. 

Sizes of types: char = 1 byte, int = 4 bytes. For enums an int is used. In 
enum types the first value is always zero and stands for Undefined. It is the 
15 recommended default value when the object is created. Unused bytes are set to 

Zero. 

The size of TSP_MSG, USMJ.EG and PARTY_LEG is variable. 

All attributes in the classes are mandatory. Some classes are mandatory 
-0 in all messages like: TSP_MSG, SIC_MSG, SI_HEAD, USM_LEG, PartyJ-EG. 

A TSP message is built in an object of class TSP_MSG, see Table 3. 
Table 4 shows the attributes in class TSPJVISG, Table 5 is the table for. protocol 
descriptors. 

The TSPJVISG is mandatory in all TSP messages. 

25 

The destjd and orgjd will now be considered. 

Destjd is the identity of the destination to which messages are sent. In the 
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network it is a reference to the SI, in Emma it is a reference to the right LVSL If the 
receiving instance doesn't exist then dest_id = 0 and the receiver knows that this 
instance has yet to be created. Destjd=0 is only valid in the first Order creating 
the SI and in Inquiries to the B-sides. 

Org jd is a reference to the address to which messages are to be sent back 
for this Instance. 

The value 0 for a Orgjd is not valid. 
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Consider the following example: 
Order 

destjd - 0 

orgjd = 73 



Inquiry to calling 
destjd = 73 
orgjd = 112 

Inquiry to called 
destjd = 0 
orgjd = 114 

Reply from calling 
destjd = 112 
orgjd = 73 

Reply from called 
destjd = 114 
orgjd = 1 9 



# Teliing this is a new SI. 

# Telling where you want the Inquiry to be 

# returned to. 



# Network sends back to the right LVSl. 

# Network tells the terminal where it wants 

# the Reply. 

# Network asks the other terminal to create a LVSl. 

# Network tells the terminal where it wants 

# the Reply. 

# Terminal sends back to the right SI. 

# Terminal tells the network where it wants 
#the CS. 

# Terminal sends back to the right SI. 

# Terminal tells the network where it wants 
#the CS. 
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CS to calling 



dest id = 73 



# Network sends back to the right LVSI. 



orgjd = 112 



# Network tells the terminal where it wants 



# new Orders. 



CS to called 



dest id = 19 



# Network asks the other terminal to create a LVSL 



orgjd = 114 



# Network tells the terminal where it wants 



# new Orders. 



The structure of the PDU for TSP/SIC is of class S!C_MSG and is given in 
Table 6. ' The attributes in class SIC_MSG are given in Table 7, Table 8 is the table 
for Message Type. 

The SIC_MSG is mandatory in all TSP/SIC messages. 

The structure of the PDU for the USM leg is of class USM_LEG and is given 
in Table 9. The attributes in class USM_LEG are given in Table 10. 

The USM_LEG is mandatory in all messages, but there is no requirement 
for there to be any elements in it. In this case, size_of_usmJeg = sizeof(int) = 4. 

In the USM_LEG the relationship upwards between objects is shown by 
putting related ASMs after its USM. ASMs under an USM is added in sequence 
after the USM and before the next USM. 

The structure of the PDU for PARTY leg is of class PARTYJ.EG and is 
given in Table 1 1 . The attributes in class PARTY J.EG are set out in Table 12. 

The PARTY_LEG is mandatory in all messages, but there is no requirement 
for there to be any elements in it. In this case size_of_partyJeg = sizeof(int) = 4. 
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In the Party leg, the relationship upwards, between objects, is indicated by 
putting a related PAE after its PE and so on. 

The classes for SI_HEAD, USM, ASM, PARTY, PE. PAE, SM and ACE all 
use the class ELEMENT_HEADJNJ_EG for common parts for all objects in the 
legs. Table 13 gives the attributes in class ELEMENT JHEADJNJ.EG: 

The terminaljd is used to identify an object sent in an order when it returns 
in an inquiry. When an object is created in SI, the networkjd is used as reference 
between LVSI and SI. The terminaljd is not be used after the object has obtained 
the networkjd. Some objects like SM and ACE are not given any terminaljd 
because they are not in the Order. The terminaljd is not unique in the SI because 
different terminals can use the same terminaljd values for different objects. 

Only the party who has initiated, i.e. ordered, the operation on the object will 
receive the terminaljd set. Other parties will receive terminaljd = 0. This can be 
used when the terminal checks if the inquiry is a result of an own order. 

A terminal doesn't know the party jd of the initiator of an Order but it does 
know if it is an operation which the terminal initiated itself. 

Fig 22 illustrates an example of the use of id. 

A Table for Element Type is set out in Table 14, a Table for Operations is 
set out in Table 1 5, a Table for Responses is set out in Table 16 and a Table for 
Causes, is set out in Table 17 

The structure of the PDU for a SI_HEAD is set out in Table 18 and Table 
19 list the attributes in the class SI_HEAD. 

The SI_HEAD is used for operations on the SI and LVSI object in the SI and 
LVSI. For example to remove a whole SI. 
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Service_Utiiity_ref is a reference to choose a Service Control in the 
Terminal. This mapping is stored locally in the Terminal. 

TCS_ref a reference to the TCSD to be used. In TSP/TCSD the attribute 
for identifying a TCSD is TCSD_HEAD::TCSDJd. Several versions of the same 
TCSD are possible, therefore an attribute for version is needed, TCS_version. 

The structure of the PDU for USM_ELEMENT is given in Table 20 and the 
attributes in class USM_ELEMENT are listed in Table 21: 

The presence should be set in the Order and not altered in the Reply/Table 
22 is the table for presence in USM. 

The structure for the PDU for an ASM_ELEMENT is given in Table 23 and 
the attributes in the class ASM_ELEMENT are listed in Table 24. 

The presence should be set in the Order and not altered in the Reply, Table 
25 is the table for presence in ASM: 

The structure of the PDU for a PARTY_ELEMENT is given in Table 26 and 
the attributes in class PARTY_ELEMENT are listed in Table 27. 

The presence should be set in the Order and not altered in the Reply, Table 
28 gives the table for presence in PARTY_ELEMENT. 

The structure of the PDU for a PARTY JD is given inTable 29 and the 
attributes in the class PARTYJD are listed in Table 30. 

The structure of the PDU for PE_ELEMENT is given inTable 31 and the 
attributes in class PE_ELEMENT are listed in Table 32. 



The presence should be set in the Order and not altered in the Reply, Table 
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The structure of the PDU for a PAE_ELEMENT is given in Table 34 and the 
attributes in the class PAE_ELEMENT are listed in Table 35. 

The presence should be set in the Order and not altered in the Reply, Table 
36 gives the table for presence in PAE_ELEMENT and Table 37 is the table for 
direction in the PAE_ELEMENT. 

The structure of the PDU for SM_ELEMENT is illustrated in Table 38 and 
the attributes in class SM_ELEMENT are listed in Table 39. 

The structure of the PDU for the ACE_ELEMENT is given in Table 40 and 
the attributes in the class ACE^ELEMENT are listed in Table 41. 

The structure of the PDU for the class TRAFFIC_DESCRIPTOR is given in 
Table 42, the attributes in class TRAFFICJDESCRIPTOR are listed in Table 43 and 
Table 44 is the table for Type in the class TRAFFIC_DESCRIPTOR. 

Attributes for changing state in TSP/SIC are set out below. 

Attribute in the message head: 

message type: { order, inquiry, reply, CS } 
Attributes in the other objects: 

operation : { none, create, modify, remove } 



response: { none, accept, reject } 
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cause: { interger value ( 0 = No cause, 1-max int = Causes) } 

The response attribute is only valid for the latest message, cause is used 
when the response == reject- 
To create an object in the other model : 

message type = order 
and for the object 



10 



operation = create 



response = none 



cause = No cause 



When the network asks the terminal: 



15 



message type = inquiry 



and in the object 



operation = create 



response = accept 



20 



cause = No cause 
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If the network can not accept something in the order: 

message type = inquiry 

and in the object 

5 operation = create 

response = reject 

cause = "Why cause" 

When the terminal accepts the inquiry: 
10 message type = reply 

and in the object 

operation = create 

response = accept 

15 cause = No cause 

or rejects something in the inquiry 

message type = reply 

20 and in the object 

operation = create 
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response = reject 

cause = "Why cause" 
When the network is responding to a reply a CS is sent: 
message type = CS 
and in the object 

operation = create 

response = accept 

cause = No cause 

In an Order the attributes Response and Cause have no meaning and the 
attribute Operation has the following meaning: 

Operation = None : The object exist and shall not be affected. 

Operation = Create : The Object shall be created. 

Operation = Modify : Attributes in the object shall be modified in some way. 

Operation = Remove : The object shall be removed. 

Table 45 lists the meaning of the attributes Operation, Response and Cause 
in an Order, Table 45 lists the meaning of the attributes Operation, Response and 
Cause in a Inquiry, Table 47 lists the meaning of the attributes Operation, 
Response and Cause in a Reply and Table 48 lists the meaning of the attributes 
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Operation. Response and Cause in a CS: 

Due to the limited number of open TCP/IP connections in Vxworks. SIGNE 
will only have one TCP-connection to every terminal for TSP/SIC. In the terminal 
the NAP, or the NET object, have to implement a mux for sharing the same 
TSP/SIC signalling channel between all local service instances, see Figure 10. For 
the other necessary connections, e.g. for registration, http, directory, etc., separate 
connections can be used. 



Mapping between messages is illustrated in Figure 11. The process of 
implementing different operations on different objects in the same message is 
illustrated in Figure 12. The process of modifying a LVSI is illustrated in Figure 13. 
The process of rolling back a LVSI is illustrated in Figure 14. The process of object 
deletion in a LVSI is illustrated in Figure 15. The process by which the Service 
Control in a terminal Handles service dependent time-outs is illustrated in Figure 
16. The process of sending Inquiries to parties who have not sent a Reply about 
changes in the SI is illustrated in Figure 17. Finally the contents of a Reply are 
illustrated in Figure 18. Figures 11 to 18 are self explanatory and will be readily 
understood by those skilled in the art and will not, therefore, be described in further 
detail. 



BNSOOCIO: <WO 001 188S*2J_> 



WO 00/11886 



-32- 



PCT/SE99/01445 



CLAIMS 

1. A teleservice management system, adapted to support the provision of a 
plurality of complex teleservices and including a plurality of intercommunicating 
subsystems, characterised in that said teleservice management system includes 
negotiation means for settling agreements between participants to a session, 
resource control architectures within terminals and a resource control architecture 
in a transmission network, said negotiation means including a telesen/ice control 
protocol for transmitting messages between said subsystems and thereby 
controlling a telesen/ice. 

2. A teleservice management system, as claimed in claim 1 , characterised in 
that said teleservice control protocol is arranged to link a network resource 
manager, service users and terminal resource managers, into a teleservice control 
process for facilitating delivery of a teleservice which is optimal, in terms of 
resource usage, and agreed by a service user. 

3. A teleservice management system, as claimed in either claim 1, or claim 
2, characterised in that said teleservice control protocol is adapted for use with a 
plurality of different teleservices. 

4. A teleservice management system, as claimed in claim 3, characterised 
in that said plurality of different teleservices include: 

multiparty, multimedia conference services; 

tele-game services; 

tele-shopping services; and 

tele-education services. 
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5. A teieservice management system, as claimed in any previous claim, 
characterised in that said teieservice control protocol .messages refer to specific 
parts of an object oriented model of a teieservice session. 

6. A teieservice management system, as claimed in any previous claim, 
characterised in that said teieservice control protocol is implemented in a 
teieservice layer and is transparently transferred in underlying layers. 

7. A teieservice management system, as claimed in claim 6, characterised in 
that said underlying layers include network layers and transport layers. 

8. A teieservice management system, as claimed in any previous claim, 
characterised in that said teieservice control protocol includes messages 
exchanged between: 

a terminal part and a network part of the teieservice management 
system; 

the teieservice management system and a service control graphical 
user interface; 

the teieservice management system and an application launcher 
daemon; and 

the teieservice management system and network resource 
managers. 

9. A teieservice management system, as claimed in any previous claim, 
characterised in that said teieservice control protocol has four primitives for 
communication within said teieservice management system. 

10. A teieservice management system, as claimed in any previous claim, 
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characterised in that said teleservice control protocol has four primitives for 
communication-with: 



a service control; 



a terminal resource manager; 



5 - a network resource manager; 



and an application daemon. 



11. A teleservice management system, as claimed in any previous claim, 
characterised in that said teleservice management system has the following 
interfaces: 

10 - a first interface, between a terminal part and a signalling emulator; 

a second interface, between a terminal and a sen/ice control; 

a third interface, between a terminal and an application launcher 
daemon; 

a fourth interface, between a terminal and a terminal resource 
15 manager; and 

a fifth interface, between a signalling emulator and a network 
resource manager. 

12. A teleservice management system, as claimed in claim 11, characterised 
in that said teleservice control protocol is adapted to transfer information relating 

20 to a part of a teleservice object model through said first interface. 
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1 3. A telesen/ice management system, as claimed in either claim 1 1 , or claim 
12, characterised in that said teleservice control protocol is adapted to transfer 
information relating to a part of a teleservice object model through said second 
interface. 

5 14. A teleservice management system, as claimed in any of claims 11 to 13, 

characterised in that said teleservice control protocol is adapted to transfer 
information relating to a name and parameters, associated with an application 
employed by a teleservice, through said third interface. 

15. A teleservice management system, as claimed in any of claims 11 to 14, 
10 characterised in that said teleservice control protocol is adapted to transfer 

information relating to a specification of terminal resources, required by a 
teleservice, through said fourth interface. 

1 6. A teleservice management system, as claimed in any of claims 11 to 15, 
characterised in that said teleservice control protocol is adapted to transfer 

15 information relating to a specification of network resources, required by a 

teleservice, through said fifth interface. 

1 7. A service platform adapted to support the provision of a plurality of complex 
teleservices and including a plurality of intercommunicating subsystems, terminals 
and a telecommunications network, characterised in that said service platform 

20 includes resource management means, and in that a teleservice control protocol 

is employed for implementing protocol agents both in said terminals and in said 
network. 

18. A sen/ice platform, as claimed in claim 17, characterised in that protocol 
agents are implemented in said terminals by utilising a resource control application 

25 provider interface, forming part of a network control architecture, as an interface 

between network resource management and a signal emulator. 

19. A service platform, as claimed in either claim 1 7, or 1 8, characterised in that 
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said terminals have at least one interface towards a user. 
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20. A service platform, as claimed in claim 19, characterised in that said 
terminals have an interface towards an application. 

21. A service platform, as claimed in either claim 19, or 20, characterised in that 
said terminals have an interface towards a terminal resource manager. 

22. A service platform, as claimed in any of claims 17 to 21, characterised in 
that said teleservice control protocol is adapted for use with a plurality of different 
teleservices. 

23. A service platform, as claimed in claim 22, characterised in that said 
plurality of different teleservices include: 

multiparty, multimedia conference sen/ices; 

tele-game services; 

tele-shopping services; and 

tele-education services. 

24. A service platform, as claimed in any of claims 17 to 23, characterised in 
that said teleservice control protocol messages refer to specific parts of an object 
oriented model of a teleservice session. 

25. A service platform, as claimed in any of claims 17 to 24, characterised in 
that said teleservice control protocol has four primitives for communication within 
said teleservice management system. 

26. A telecommunications system, logically split between an application layer, 
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a teleservice layer, a bearer service layer and a resource layer, characterised in 
that said teleservice layer includes a teleservice management system as claimed 
in any of claims 1 to 16. 

27. A method of managing a plurality of complex teleservices employing a 
teleservice management system including a plurality of intercommunicating 
subsystems, characterised by settling agreements between participants to a 
session by exchanging messages using a teleservice control protocol, and by said 
teleservice control protocol linking a network resource manager, sen/ice users and 
terminal resource managers into a teleservice control process for facilitating 
delivery of a teleservice which is optimal in terms of resource usage and agreed by 
a service user. 

28. A method as claimed in claim 27, characterised by said teleservice control 
protocol operating with a plurality of different teleservices. 

29. A method, as claimed in claim 28, characterised by said plurality of 
different teleservices including: 

multiparty, multimedia conference services; 

tele-game services; 

tele-shopping services; and 

tele-education services. 

30. A method, as claimed in any of claims 27 to 29, characterised by said 
teleservice control protocol messages referring to specific parts of an object 
oriented model of a teleservice session. 



31. A method, as claimed in any of claims 27 to 30, characterised by 
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implementing said teleservice control protocol in a teleservice layer and by 
transparently transferring teleservice protocol messages in underlying layers. 

32. A method, as claimed in any of claims 27 to 31, characterised by said 
underlying layers including network layers and transport layers. 

5 33. A method, as claimed in any of claims 27 to 32, characterised by said 

teleservice control protocol including messages exchanged between: 

a terminal part and a network part of the teleservice management 
system; 

the teleservice management system and a service control graphical 
10 user interface; 

the teleservice management system and an application launcher 
daemon; and 

the teleservice management system and network resource 
managers. 

15 34. A method, as claimed in any of claims 27 to 33, characterised by said 

teleservice control protocol having four primitives for communication within said 
teleservice management system. 

35. A method, as claimed in any of claims 27 to 34, characterised by said 
teleservice control protocol having four primitives for communicating with: 

20 a service control; 

a terminal resource manager; 
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a network resource manager; 

and an application daemon. 

36. A method, as claimed in any of claims 27 to 35 t characterised by said 
teleservice management system having the following interfaces: 

a first interface, between a terminal part and a signalling emulator; 

a second interface, between a terminal and a service control; 

a third interface, between a terminal and an application launcher 
daemon; 

a fourth interface, between a terminal and a terminal resource 
manager; and 

a fifth interface, between a signalling emulator and a network 
resource manager. 

36. A method, as claimed in claim 35, characterised by using said teleservice 
control protocol to transfer information relating to a part of a teleservice object 
model through said first interface. 

37. A method, as claimed in either claim 35 or 36, characterised by using said 
teleservice control protocol to transfer information relating to a part of a teleservice 
object model through said second interface. 

38. A method, as claimed in either claim 35 or 37, characterised by using said 
telesen/ice control protocol to transfer information relating to a name and 
parameters, associated with an application employed by a teleservice, through said 
third interface. 
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39. A method, as claimed in either claim 35 or 38, characterised by using said 
teleservice control protocol to transfer information relating to a specification of 
terminal resources, required by a teleservice, through said fourth interface. 

40. A method, as claimed in either claim 35 or 38, characterised by using said 
5 teleservice control protocol to transfer information relating to a specification of 

network resources, required by a teleservice, through said fifth interface. 
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Callinq Terminal ! 


Network i Called Terminal 






I 




Calling sends a 
Order 










— Order - — > 














Network processes the 
Order and sends Inquiries 










< — Inquiry — > 






The terminal 
allocates the ABB 
and sends a Reply 










— Reply — > 

i 








The terminal ask the user j 
to join. If he joins, the 1 
terminal allocates the ABB j 
and sends a Reply i 


i 


Network uodates the SI 




i 










< — Reply — 






Network updates the SI 
and finds that the 
minimum demands for 
setting up a SI is fullfilled , 
tells the resources in the 
network to activate. The 
two terminals are now 
connected. Network 
sends Confirmed State to 
both terminals. 






i 


<— CS — > 






The terminal 
activates the ABB 
and starts to 
communicate with 
the other terminal 








The terminal activates the 
ABB and starts to 
communicate with the other 
terminal 













FIGURE 19 
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Calling Terminal 




Network ! i Called Terminal ! 






1 


i 

i 


The calling terminal 
is communicating 
with the other 
terminal and deside 
to terminate the SI. 
An Order about 
termination is sent to 
the network. 




i 
j 

i 
i 

j 




The called terminal is | 
communicating with the other ; 
terminal. ; 

i 
I 


— Order - — > 








1 

l 


i 1 




Network processes the 
Order and sends 
Inquiries to the 
involved partys. 




i 

i 
j 

i 




! <— tnauirv — > 


! ! 


The terminal tells the 
ABB to finish and 
when it is done it 
sends a Reply. 










— Reply — > 

i 

' 








The terminal knows it is time to 
terminate the SI, finish the 
current transfer and exiting the i 
ABB and sends a reply to the ] 
network. 1 


1 
1 


l 

| 


Network updates the J 
SI i 










<— Reply — 






Network updates the 
SI. deactivates the 
resources, disconnects 
the terminals and 
sends Confirmed 
State. 




1 

i 

i 
i 






<— CS — > 




i 


The Confirmed State 
message tells the 
terminal that the SI 
has ended and the 
LVSI can be thrown 
away. 


i 

i 

i 






The Confirmed State message 
tells the terminal that the SI 
has ended and the LVSI can ] 
be thrown away. ! 

i 




i 


! 
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Object in Terminal Object in Message Object in Network 



the_object 

state = created in 
terminal 



— Order — > 

the_object 

operation=create 
response=none 



The object is created in the 
network 



the_obiect 
state=created 



The object is reserved in the 
network 



the_object 
state=reserved 



< — Inquiry — 

the_object 

operation=create 
response=accept 



the_object 

state=lnquired by 
network 



Reservation of resources 
in the terminal 



the_object 



state=Reserved in 
terminal 



FIGURE 21 
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— Reply — > 

j the_object 

j operation=create 
j response=accept 

i 



the_object 

state=Partty confirmed 



Confirmed by the other 
parties 



<— 



CS » 



the_object 



operation=create 
response=accept 



the_object 



state=Activated in 
network 



the_object 



state=Confirmed 



Activated in the network 



the_object 



state=Activated 



Activated in the terminal 



the_object 



state=Activated 



In this state the 
terminals are in 
communication 



Figure 21 cont 
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Object in Terminal 



the object 



state = created in 
terminal 
networkjd = -1 
terminal id = 42 
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Object in Message 



LVSI sets terminaMd to a 
unique value for the LVSI 
and network id to -1 



Order — > 



the_object 



operation=create 
response=none 
networkjd = -1 
terminal id = 42 



Object in Network 



The object is created 
and reserved in the 
network 



Reservation in the 
terminal 



SI creates the object in 
the network and sets a 
Unioue network id 



< — Inquiry — 



the_object 



operation=create 
response=accept 
networkjd = 0x4424 
terminal id = 42 



LVSI looks for an object 
with the networkjd, if 
LVSI can't find any object 
it looks for an object v/ith 
the terminaMd, if LVS! 
can't find the object it 
creates the object. In this 
example it finds it using 
the terminal id 



the_object 



staie=reserved 
networkjd = 0x4424 
terminal id = 42 



SI sends both networkjd 
and terminal id to LVSI 



FIGURE 22 



Continued on next 
sheet 
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the_object 

state=Reserved in 
terminal 

networkjd = 0x4424 
terminal id = 42 



In this example it finds it 
using the terminaMd and 
LVSI updates the local 
object. From here 
networkjd is used for 
identifying the object. 

— Reply — > 



the_object 



operation=create 
response=accept 
networkjd = 0x4424 
terminal id = 42 



SI uses network id. 



When activated in ths 
network 



ihe_object 



state=Activated 
networkjd = 0x4424 
terminal id = 42 



LVSI uses the necv/orkjd to 
identify the object. 



the_object 



operation=create 
response=ac.cept 
networkjd = 0x4424 
terminal id = 42 



the_object 



state=Activated in 
network 

networkjd = 0x4424 
terminal id = 42 



Activated in the termini 



FIGURE 22 cont, 
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Information 1 
Interface 

between EMMA/SIGNE 


Table 1 " " 

rransferred through Various TSMS Interfaces 
Information Transferred 


between fcMMA/SC 
between EMMA/APLD 


a part of the teleservice object model 

a part of the teleservice obiect model 

name ana parameters of the appiications(s) involved in "" 1 

the teleservice 


between EMMA/TRM 


specification of terminal resources required bv the 
teleservice 


u CL w C . :i specmcation of network resources requtred by the 1 

1 teleservice 
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Table 2 

Typical Messages for Establishing a Teleservice Session between Two Parties 





Messaae Name 


Source 


Destination 


1 


SC-Order 


SC1 


EMMA1 


2 


UA-Check 


EMMA1 


APLD1 


3 


UA-Check-Response 


APLD1 


EMMA1 


4 


Terminal-Check 


EMMA1 


TRM1 


5 


Terminal-Check-Resp. 


TRM1 


EMMA1 


6 


Order 


EMMA1 


SIGNE 


7 


Network-Check 


SIGNE 


NRM 


8 


Network -Check-Resp. 


NRM 


SIGNE 


9 


Inquiry 


SIGNE 


EMMA1 . EMMA2 


10a 


UA-Check 


EMMA2 


APLD2 


11a 


UA-Check-Response 


APLD2 


EMMA2 


12a 


Terminai-Check 


EMMA2 


TRM2 


13a 


Terminal-Check-Resp. 


TRM2 


EMMA2 


14a 


SC-lnquiry 


EMMA2 


SC2 


15a 


SC-Reply 


SC2 


EMMA2 


16a 


Reply 


EMMA2 


SIGNE 


10b 


SC-lnquiry 


EMMA1 


SC1 


11b 


SC-Reply 


SC1 


EMMA1 


12b 


Reply 


EMMA1 


SIGNE 


17 


Network-Start 


SIGNE 


NRM 


18 


Network -Start-Resp. 


NRM 


SIGNE 


19 


Confirmed State 


SIGNE 


EMMA1 , EMMA2 


20a 


UA-Start 


EMMA1 


APLD1 


21a 


UA-Start-Response 


APLD1 


EMMA1 


22a 


Terminal-Start 


EMMA1 


TRM1 


23a 


Terminal-Start-Resc. 


TRM1 


EMMA1 


24a 


SC-CS 


EMMA1 


SC1 


20b 


UA-Start 


EMMA2 


APLD2 


21b 


UA-Start-Response 


APLD2 


EMMA2 


22b 


Terminal-Start 


EMMA2 


TRM2 


23b 


Terminal-Start-Resp. 


TRM2 


EMMA2 


24b 


SC-CS 


EMMA2 


SC2 
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Table 3: Structure of a TSP Message 



Syncword=H 
ELLO 
SIGNE! 
(12 bvtes) 


prot = 
TSP/SIC 
(4 bytes) 


tsp_rev 
(4 bytes) 


org_id 
(8 bytes) 


destjd 
(8 bytes) 


username 
( 20 bytes) 


Hostname 
(60 bytes) 


tot_size_of_msg 
(4 bytes) 


prot_data = SIC_MSG 
( xx bvtes) 



Table 4: Attributes in Class TSP_MSG 


No I 


Type 


Name 


Description 


1 


const charM 2] 


Syncword 


Value: "HELLO SIGNE!" 


2 


int 


prot ! Protocol descriptor. See table. 


3 


const int | tsp_rev 


Revision of the TSP MSG. This rev = 3 


,1 


int [2] 


org_id 


Originating Instance identifyer and return 
adress. Org_id=0 is not valid. ! 


5 


int [2] 


destjd 


Destination identifyer. if 0 create a new 
instance. 


6 


char [20] 


username 


username in the terminal (Never the username 






of the process owner in the network (SIGNE)) 


7 


char [60] 


hostname 


hostname of the terminal. (OBS! Max size in 






Solaris 2.5 is 256 bytes) 


8 


int 


tot„size_of_msg 


Size of the TSP messaae in bytes 


9 


char [xx] 


prot_data 


PDU. size is (tot_size_of_msg - "other attributs 
in classTSP_MSG"). 



Table 5: Protocol Descriptor for TSP Message 


Value 


Name 


Description 


0 


Undefined 


Undefined 


1 


TSP/SIC 


Service Instance control protocol 


2 


TSPATCSD 


TSC description protocol 


3 


TSP/DIR 


Directory protocol 


4 


TSP/Term Profile 


Terminal profile protocol 


5 


TSP/REG 


Registration protocol 


6 


TSP/MUX 


For control messages between the 
muxes. 


7 


TSP/ITCSD 


Signe Internal TSC description protocol 


8 to max int 




ffs 
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Table 6: PDU for TSP/SIC 


message type 
(4 bvtes) 


stc_rev 
(4 bvtes) 


si_head i usmjeg 
( xx bvtes) i 'xx bvtes^ 


party Jeg 
(xx bvtes) 







Table 7: Attributes in Class SIC MSG 




No 


Type 


Name 


Description 


i 


1 


int 




message tvDe 


See Table 


! 


2 


const int 




sic rev 


Revision of TSP/SIC, This rev = 




3 


class SI 


HEAD 


si head 


See class SI HEAD 


I 


4 


char [xx] 


usm leg 


PDU for USM leg 


5 


char fxxl 




oartv lea 


PDU for PARTY lea 


! 

1 



Table 8: Table for Message type 


Value I Name 


Description 


0 | Undefined 


Undefined 


1 ! ORDER 


Sent from Terminal 


2 I INQUIRY 


Sent from Network 


3 | REPLY 


Sent from Terminal 


4 ICS 


Sent from Network 


5 to max int - 


ffs 



Table 9: PDU for USM Leg 


size_of_usm leg 
(4 bvte) 


elements 

((size of usm lea - 4) bvtes) 



Table 10: Attributes in Class USM LEG 

No i Type I Name | Description 

1 l int I size_of usm leg I Size of the USM ieg in bytes 

2 I char fxxl I elements I PDU for USMs and ASMs 
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Table 11: PDU for PARTY LEG 



size_of_partyJeg 
(4 byte) 



elements 

((size_of_partyJeg - 4) bytes) 



Table 12: Attri 


butes in Class PART LEG 


No 


Type 


Name 


Description 


1 


int 


size_of_party_leg 


Size of the Party leq in bytes 


2 


char [xx] 


elements 


PDU for PARTY. PEs. PAEs. SMs and ACEs 



Table 13: Attributes in Class ELEMENT HEAD IN LEG 


No 


Type 


Name 


Description 


1 


int 


element_type 


Type of Element. See table. I 


2 


int 


networkjd 


Unique for the Service Instance. Primary id. 


3 


int 


terminal_id 


Unique for LVSI of initiator. Used of LVSI until 
network id not equal to -1 . 


4 


int 


operation 


Operation on the object. See text and table. 


5 


int 


response 


Response to the operation. See text and tabie. 


6 


int 


cause 


Cause value. See table. 



Table 14: Table for Element Type 


Value 


Name 


Description 


0 I Undefined 


Undefined 


1 SUSM OBJECT | 


2 


ASM OBJECT i ! 


3 ! PARTY OBJECT I Not used in TSP/TCSD 


4 


PE OBJECT I 


5 


PAE_OBJECT 




6 


SM_OBJECT 




7 


ACE OBJECT 




8 


SI_HEAD_OBJECT 


Not used in TSP/TCSD 


9 


TCSD_HEAD_OBJECT 


Not used in TSP/SIC 


10 


PARTY_TYPE"_OBJECT 


Not used in TSP/SIC 


1 1 to max int ! - 


ffs 
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Table 15: Table for Operation 


Value 


Name 


Description 


0 


Undefined 


Undefined 


1 


NONE 


See text. 


2 


CREATE 


See text. 


3 


MODIFY 


See text. 


4 


REMOVE 


See text. 


5 to max int 




ffs 



Table 16: Table for Response 


Value 


Name 


Description 


0 


Undefined 


Undefined 


1 


NONE 


See text. 


2 


ACCEPT 


See text. 


3 


REJECT 


See text. 


4 to max int 




ffs 
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Table 18: PDU for SI HEAD 




head 


Service Utility ref 


TCS_ref 


TCS_version | 


(28 bytes) 


( 4 bvtes) 


(4 bvte) 


(4 bvtes) I 





Table 19: Attributes in Class SI HEAD 


No 


Type 


Name 


Description 


1 


class 

ELEMENT HEAD IN L 
EG 


head 


Common attribuis 


2 


int 


ServiceJJtilit 
y_ref 


End to end, reference 
for the utility of the 
sen/ice 


3 


int 


TCS_ref 


Reference to the . 
TCSD 


4 


int 


TCS version 


Version of the TCSD-. 



Table 20: PDU for USM 


ELEMENT 


head 

(28 bvtes) 


type 

(4 bvtes) 


presence 
(4 bvtes) 



Table 21: Attributes in class USM ELEMENT 


No 


Type 


Name 


Description 


1 


class ELEMENT HEAD IN LEG 


head 


Common attributs 


2 


int 


type 


See table for 
USM::Type in 
TSPTCSD.DOC 


3 


> n t I Dresence 


See table 



Table 22: Table for presence in USM 


Value | Name 


DescriDtion 


0 | Undefined 


Undefined 


1 I Mandatory 




2 Ootional 




3 to max int I - 


ffs 
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Table 23: PDU for ASMELEMEN1 


head 

(28 bytes) 


type 

(4 bytes) 


presence I quality 
(4 bytes) 1 (4 bytes) 



Table 24: Attributes in c 


ass ASM ELEMENT 


No 


Type 


Name 


Description 


1 


class 

ELEMENT_HEAD_IN_LEG 


head 


Common attributs 


2 


int 


type 


See table for ASM::Type 
in TSPTCSD.DOC 


3 


int 


presenc 
e 


See table 


4 


int 


quality I ffs. 



Table 25: Table for presence in ASM 


Value 


Name 


Description 


0 


Undefined 


Undefined 


1 


Mandatory 




2 


Optional 




3 to max int 




ffs 



Table 26: PDU for PARTY ELEMEfl 


head 

(28 bytes) 


type 

(4 bytes) 


presence 
(4 bytes) 


party_id 
(100 bytes) 



Table 27: Attributes in class PARTY ELEMENT 


No 


Type 


Name 


Description 


1 


class ELEMENT_HEAD_IN_LEG 


head 


Common attributs 


2 


int 


type 


Reference to a Party_type 

in TCSD. 

See table for 

PARTY TYPE::Role in 

TSPTCSD.DOC 


3 


int 


presence 


See table 


4 


class PARTY ID 


party_id 


ffs. 
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Table 28: Table for presence in PARTY ELEME 


Value 


Name 


Description 


0 


Undefined 


Undefined 


1 


Mandatory 




2 


Optional 




3 to max int 


| ff s 



Table 29: PDU for PARTY ID 


name 
(20 bytes) 


terminalname 
(60 bytes) 


E164address 
(20 bytes) 







Table 30: Attributes in class PARTYJD 


No 


Type 


Name 


Description 


1 


char[20] 


name 


Name, can be same vaiue as 
username in the terminal. ^ 


2 


char[60] 


terminalname 


Terminalname, can be same value 
as the hostname of the terminal. 


3 


unsigned 
char[20] 


E164address 


To be used when a terminal don't 
support SIGNE and TSP, like a 
Q.2931 terminal. 



Table 31: PDU for PE ELEMENT 


| head 

I (28 bytes) 


usm_ref 
(4 bytes) 


usm_terminal_ref 
(4 bytes) 


presence 
(4 bytes) 



Table 32: Attributes in class PE ELEMENT 


No 


Type I Name 


Description 


1 


class ELEMENT_HEAD_IN_LEG | head 


Common attributs 


2 


int 


usm_ref 


Reference to USM 


3 


int 


usm terminal r 
ef 


Ref to USM using 
terminaLid 


4 


int 


presence 


See table 
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Table: 33 Table for presence in PE ELEMENT 


Value 


Name 


Description 


0 


Undefined 


Undefined 


1 


Mandatory 




2 


Optional 




3 to max int 




ffs 



Table 34: PDU for PAE ELEMENT 


head 

(28 bytes) 


asm_ref 
(4 bytes) 


asm terminaLre 
f 

(4 bytes) 


presence 
(4 bytes) 


direction 
(4 bytes) 



Table 35: Attributes in class PAE ELEMENT 



No 


Type 


Name 


Description 


1 


class ELEMENT_HEAD_IN_LEG 


head 


Common attributs 


2 


int 


asrn_ref 


Reference to ASM 


3 


int 


asm terminator 


Ref to ASM usning 






ef 


terminal id 


4 


int 


presence 


See table 


5 


int 


direction 


Mapping direction for the 








PAE 



Table 36: Table for presence in PAE ELEMEls 


Value 


Name 


Description 


0 


Undefined 


Undefined 


1 


Mandatory 




2 


Optional 




3 to max int 




ffs 



Table 37: Table for direction in PA 


E ELEMENT 


Value 


Name 


Description 


0 


Undefined 


Undefined 


1 


Send 




2 


Receive 




3 


Send and Receive 




4 


None 




5 to max int 




Undefined 
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Table 38: PDU for SM ELEMENT 


head 
(28 bytes) 


type 

(4 bytes) 


ABBparam 
(256 bytes) 
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Table 43: Attributes in class TRAFFIC DESCRIPTOR 


No 


Type 


Name 


Description 


1 


int 


Type 


Traffic Class Type. See table belowe. 


2 


int 


Param 


Parameter for the Traffic Class. 



Table 44: Table for Ty 


pe in class TRAFFIC DESCRIPTOR 


Value Name 


Description 


0 Unknown 


defined for unknown 


1 I Free 


Telia Free Class. 


2 ! Guaranteed 


Telia Guaranteed Class. 


3 to max int j - 


ffs 
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Table 45: The meaning of the attributes Operation, Response and Cause in 

an Order 


Operation 


Respons 
e 


Cause 


Valid 


Description 












None 


None 


None 


Valid 


Object exist but no action is 
heeded. 


None 


None 


Value 


Not Valid 




None 


Accept 


None 


Not Valid 




None 


Accept 


Value 


Not Valid 




None 


Reject 


None 


Not Valid 




None 


Reject 


Value 


Not Valid | 


Create 


None 


None 


Valid I In Order to Create a object. 


Create 


None 


Value 


Not Valid 1 


Create 


Accept | None 1 Not Valid | 


Create 


Accept 


Value 1 Not Valid t 


Create 


Reject 


None 


Not Valid 




Create 


Reject 


Value 


Not Valid 




Modify 


None 


None ! Valid 


■ In Order to Modify the object. 


Modify 


None 


Value ! Not Valid 




Modify 


Accept 


None 


Not Valid 




Modity 


Accept 


Value 


Not Valid 




Modify 


Reject 


None 


Not Valid 




Modify 


Reject 


Value 


Not Valid 




Remove 


None 


None 


Valid 


In Order to Remove the object. 


Remove 


None 


Value 


Not Valid 




Remove 


Accept 


None 


I Not Valid 


i 


Remove 


Accept 


Value 


Not Valid i 


Remove 


Reject 


None 


Not Valid j 


Remove 


Reject 


Value 


Not Valid I 
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Table 46: The meaning of the attributes Operation, Response and Cause in 

an Inquiry 


Operation 


Response 


Cause Valid 


Description 


None 


None 


None Valid 


Object exist but no action is needed. 


None 


None 


Value ! Not Valid 




None 


Accept 


None 


Not Valid 




None 


Accept 


Value 


Not Valid 




None 


Reject 


None 


Not Valid 




None 


Reject 


Value 


Not Valid 




Create 


None 


None 


Valid 


Object exist but no action is needed. 


Create 


None 


Value 


Not Valid 




Create 


Accept 


None 


Valid 


The network accept creation of this 
object and asks the terminal if it 
accepts a creation of this object. 


Create 


Accept 


Value 


Not Valid 




Create 


Reject 


None 


Not Valid 


Create 


Reject 


Value 


Valid 


The network reject creation of this 
object. This is valid when it is sent to 
the sender of the Order 


Modify 


None 


None 


Valid 


Object exist but no action is needed. 


Modify 


None 


Value | Not Valid 




Modify 


Accept 


None 


Valid 


The network accept modification of 
this object and asks the terminal if it 
accepts a modification of this object. 


Modify 


Accept 


Value 


Not Valid 




Modify 


Reject 


None 


Not Valid 




Modify 


Reject 


Value 


Valid 


The network reject modification of 
this object. This is valid when it is 
sent to the sender of the Order 


Remove 


None 


None 


Valid 


Object exist but no action is needed. 


Remove 


None 


Value 


Not Valid 




Remove 


Accept 


None 


Valid 


The network accept removal of this 
object and asks the terminal if it 
accepts a removal of this object. 


Remove 


Accept 


Value 


Not Valid 




Remove 


Reject 


None 


Not Valid 




Remove 


Reject 


Value 


Valid 


The network reject removal of this 
object. This is valid when it is sent to 
the sender of the Order 
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Table 47: The meaning of the attributes Operation, Response and Cause in a 

Reply 


Operation 


Respons 
e 


Cause 


Valid 


Description 












None 


None 


None 


Valid 


Object exist but no action is 
needed. 


None 


None 


Value 


Not Valid 




None 


Accept 


None 


Not Valid 




None 


Accept 


Value 


Not Valid 1 


None 


Reject 


None 


Not Valid I 


None 


Reject 


Value 


Not Valid j 


Create 


None 


None 


Valid ! Object exist but no action is 
1 needed. 


Create ! None 


Value 


Not Valid ! 


Create 


Accept 


None 


Valid j The terminal accept creation of this 
1 object. 


Create ! Accept 


Value 


Not Valid 1 


Create I Reject 


None 


Not Valid 




Create 


Reject 


Value 


Valid 


The terminal reject creation of this j; 
object. 


Modify 


None 


None 


Valid 


Object exist but no action is 
needed. 


Modify 


None 


Value 


Not Valid 




Modify 


Accept 


None 


Valid 


The terminal accept modification of 
this object. 


Modify 


Accept 


Value 


t Not Valid 




Modify 


Reject 


None 


Not Valid 




Modify 


Reject 


Value 


Valid 


The terminal reject modification of 
this object. 


Remove 


None 


None 


Valid 


Object exist but no action is 
needed. 


Remove 


None 


Value 


Not Valid 




Remove 


Accept 


None 


Valid 


The terminal accept removal of this 
object. 


Remove 


Accept 


Value 


Not Valid 




Remove 


Reject 


None 


Not Valid 




Remove 


Reject 


Value 


Valid 


The terminal reject removal of this 
object. 
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Table 48: The meaning of the attributes Operation, Response and Cause in a 

CS 


Operation 


Response 


Cause 


Valid | Description 












None 


None 


None 


Valid 


Object exist but no action is 
needed. 


None 


None 


Value 


Not Valid 




None 


Accept 


None 


Not Valid 




None 


Accept 


Value 


Not Valid 




None 


Reject 


None 


Not Valid 




None 


Reject 


Value 


Not Valid 




Create 


None 


None 


Valid 


Object exist but no action is 
needed. 


Create 


None 


Value 


Not Valid 




Create 


Accept 


None 


Valid 


The object is created in network j 
and accepted in terminals. j 


Create 


Accept 


Value 


Not Valid 


i 

! 


Create 


Reject 


None 


Not Valid 




Create 


Reject 


Value 


Valid 


The object is not created because 
of either network och a terminal 
has rejected it 


Modify 


None 


None 


Valid 


Object exist but no action is 
needed. 


Modify 


None 


Value 


Not Valid 




Modify 


Accept 


None 


Valid 


The object is modifyed in network. 


Modify 


Accept Value 


Not Valid 




Modify 


Reject 


None 


Not Valid 




Modify 


Reject 


Value 


Valid 


The object is not modifyed because 
of either network och a terminal 
has rejected the modification 


Remove 


None 


None 


Valid 


Object exist but no action is 
needed. 


Remove 


None 


Value 


Not Valid 




Remove 


Accept 


None 


Valid 


The object is removed in network. 


Remove 


Accept 


Value 


Not Valid 




Remove 


Reject 


None 


Not Valid 




Remove 


Reject 


Value 


Valid 


The removal of the object is 
rejected by either the network or a 
terminal 
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